Embodiments in accordance with the present invention relate generally to computer systems and Ethernet-based networking, and, more specifically, relate to systems that intercept messages between HSMS entities in a semiconductor manufacturing environment.
Most modern equipment used for the manufacturing of semiconductors (typically referred to as “tools”) come outfitted with a SEMI Equipment Communication Standard (SECS) compliant interface. Often, factory host automation systems (or “hosts” for short) are used to automate the scheduling and recipe selection for these tools. The SECS protocol was initially created circa 1980 to ensure a standard interface existed across equipment manufacturers, so that tools and hosts from different manufacturers would be interoperable. Most modern semiconductor manufacturing facilities automate the operation of the tool by using a factory host system, as shown in FIG. 1.
FIG. 2 describes the protocol stack for SECS communication. Initially, the SECS protocol consisted of two messaging layers. SECS-I is a transport layer based on RS-232 (point-to-point serial). SECS-II is a messaging layer which describes a well-defined message format. Sending SECS-II messages over a SECS-I link, a host could send instructions to the tool, as well as query the tool for status information.
In some cases it may be advantageous to allow an entity other than the host to send SECS-II messages to the tool, or to have an entity other than the tool send SECS-II messages to the host. For example, a third party end-point system on a plasma etcher may need certain information from the tool, such as the current recipe running on the tool, the current step being processed on the tool, and current chamber parameters (i.e. pressure, temperature, power, etc.)
In many cases, however, the only standard method of retrieving this kind of information from the tool is through the SECS interface. Since the SECS-I communication link is based on RS-232 which is point-to-point, and the host and tool are already connected point-to-point, there is no room for a third entity to participate in the SECS communication between the host and the tool.
In order to allow a third entity to participate in the SECS communication, an entity (called the “pass-through agent”) may be placed between the host and tool, such that it becomes the intermediary of all SECS communication between the host and tool. FIG. 3 shows a simplified schematic view of a pass-through Agent for a SECS-I Communications Link.
In the configuration shown in FIG. 3, the pass-through agent reads all SECS-II messages from the tool and forwards it to the host, and vice versa. Because RS-232 is point-to-point without specific addressing, the pass-through agent can simply be placed physically in between the tool and the host, and neither tool nor host needs to be reconfigured in any way. In such a manner, the pass-through agent can view all messages going between the tool and the host, and can create new messages and send them to the tool as if they came from the host, and vice versa.
Such a method of invisibly intercepting communications between two entities are commonly referred to as “man-in-the-middle” schemes. Such methods are useful, for example, in allowing a third system to collect data directly from the tool, or for sending commands directly to the tool without having to interface with a host system. FIG. 4 illustrates a simplified schematic view of a high level process for a rudimentary pass-through agent illustrated in FIG. 3.
A “bypass” mechanism can also be incorporated into a pass-through agent. Such a bypass mechanism allows host-tool communication to continue even in the event of failure of the pass-through agent. One example of a bypass mechanism is a serial communication card containing two serial ports which can be mechanically shunted together if power is lost. If the pass-through agent should fail, the two ports of the serial communication card would be shunted together to form the equivalent of a serial cable in between the two ports, and thus between the tool and host. FIG. 5 shows a simplified block diagram of an embodiment of such a bypass card.
Circa 1995, about 15 years after SECS-I was created, a newer SEMI protocol called High Speed SECS Message Services (HSMS) was created. HSMS replaced the SECS-I layer in the SECS communication protocol, while keeping the SECS-II message format in place. FIG. 6 shows a simplified schematic view of the SECS protocol stack using HSMS. As evident from comparing FIG. 6 to FIG. 2, in HSMS, SECS-I and below have been replaced by HSMS on top of TCP/IP.
While SECS-I was a point-to-point RS-232 serial protocol, HSMS is a TCP/IP based network protocol on Ethernet. A major difference between these two is that the SECS-I communication link is physically point-to-point, while the TCP/IP-based HSMS communication link is a virtual one across an Ethernet network that could contain many nodes. FIG. 7 provides a simplified schematic view of an example of an Ethernet network configuration.
With HSMS, many devices can be networked over a hub. When one device sends a message to another device over the Ethernet, the message is broken down into TCP/IP packets which are broadcasted to all devices on the hub. Each device compares its own IP address to the destination IP address in the TCP/IP packets, and if there is a match the device will read the packets. If there is not a match, the device would typically ignore the packets. Since HSMS uses TCP/IP with defined source and destination addressing, it becomes difficult to implement the pass-through agent by simply putting something physically in between in the same manner described for SECS-I.
One approach for implementing a pass-through agent is to configure the host and tool to send HSMS messages to the IP address and port of an intermediary pass-through agent, and have the intermediary then forward the messages to the other entity. FIG. 8 shows a simplified schematic view of one embodiment of such a configuration.
However, the approach shown in FIG. 8 may offer some issues. For example, in FIG. 8, the intermediary is not invisible. Both the host and the tool need to be reconfigured to point to the IP address and port of this new intermediary.
Moreover, in the configuration of FIG. 8 the software performing the forwarding function would only forward HSMS messages. Other types of network traffic that are supposed to go from tool to host and vice-versa (such as SNMP packets), might not be forwarded by the intermediary.
The apparatus of FIG. 8 also fails to provide a mechanism for a fail-safe bypass. If the intermediary failed, the host and tool would continue trying to send HSMS messages to the IP address of the failed intermediary. Even if a bypass card similar to the one shown in FIG. 5 used for SECS-I were employed, the host and tool would still be attempting to send messages to the IP address of the failed intermediary. The end result would be a loss of HSMS communication between the host and tool.
In view of the above, there is a need in the art for methods and apparatuses involving improved pass-through communication under the HSMS standard.